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Executive Summary 

CanSat is an international student design-build-launch competition organized by the 
American Astronautical Society (AAS) and American Institute of Aeronautics and Astronautics 
(AIAA). The competition is also sponsored by the Naval Research Laboratory (NRL), the 
National Aeronautics and Space Administration (NASA), AGI, Orbital Sciences Corporation, 
Praxis Incorporated, and SolidWorks. Specifically, the 2009 Virginia Tech CanSat Team is 
funded by BAE Systems, Incorporated of Manassas, Virginia. The objective of the 2009 CanSat 
competition is to complete remote sensing missions by designing a small autonomous sounding 
rocket payload. The payload designed will follow and perform to a specific set of mission 
requirements for the 2009 competition. The competition encompasses a complete life-cycle of 
one year which includes all phases of design, integration, testing, reviews, and launch. 


ii 



Table 1: Applicable Documents 


Document Title 

Description of Document 

2009 CanSat Competition Design Guide [1] 

Outlines the requirements and missions for the 
competition. 

Practice Standard for Work Breakdown 
Structures (Second Edition) [2] 

Provides guidance and universal principles for 
the initial generation, subsequent development, 
and application of the Work Breakdown 
Structure. 

Obemdorf, T. Software Engineering Institute: 
Carnegie Mellon. Open Systems, from 
http://www.sei.cmu.edu/opensystems/faq.html 

_[ 3 ] 

Website that provides information on open 
systems architecture. 
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1 Introduction 

1.1 Objective 

CanSat is a unique space design competition because it allows teams to actually 
implement their designs through construction and competition. Sponsored by the ALA.A and the 
AAS, the annual CanSat competition features a remote sensing theme for the 2009 competition 
year. Teams of up to ten students have the mission of designing and building a CanSat that is 
launched and deployed from about 900 meters altitude and autonomously navigates to a 
predefined landing coordinates. In order to meet these requirements, the team is responsible for 
designing, constructing, and testing structures, mechanisms, communications devices, and 
automated control devices. 

1.2 Background Information 

The CanSat is literally what its name implies; a satellite the size of a soda can. The 
team’s mission is to create a small landing module, which fits in an amateur rocket payload bay 
(refer to Figure 12 in the Appendix), measuring 72 mm in diameter and 280 mm in height. The 
CanSat is launched to an apogee of approximately 900 meters, where it is released from the 
rocket payload section (see Figure 1). A ram-air parachute is used to control the decent, and 
upon landing, mechanisms are activated to place the CanSat in its upright position. Our design 
has the CanSat coming to rest on its side, then employing spring loaded arms to rotate the CanSat 
so its top side and solar panels are facing up. During the entire flight, altitude, GPS, and 
housekeeping telemetry will be communicated to the ground station at regular intervals. These 
requirements; descending at a controlled rate, functioning autonomously, and transmitting 
telemetry, make up the CanSat primary mission. 
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Ejection charge separates payload/ 
nose section from rocket. When 
front section separates from rocket 
the shock chord between them pulls 
the rocket parachute from the 
rocket 




Cansat rests on its parachute. 

The nose cone parachute rests on the 
bottom of the cansat 



The cansat, nose cone, and rocket 
descend under parachutes 




Figure 1. Concept of Operations for CanSat Deployment [1]. 


The primary mission is successfully completed if all minimal CanSat requirements are 
met. In addition points are next awarded for completing bonus missions. The bonus missions 
include autonomous navigation to a predefined set of coordinates downwind of the launch site, 
additional housekeeping telemetry, landing image, and solar powered system. Our design will 
implement an autonomous navigation system, five additional telemetry data, and solar panels to 
power the CanSat’s operation after landing. 
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2 Systems Engineering Process 

2.1 Systems Engineering Process Planning 

Figure 2 shows the “Systems Engineering ‘V’ Diagram” for decomposition, definition, 
integration, and recomposition of a system over its entire lifecycle. Figure 2 is used throughout 
the design process to develop verification planning for subsystems of the CanSat. 



Figure 2. Systems Engineering Decomposition and Integration ‘V’ [2], 


2.1.1 Major Products and Results from Process 

The major products and results for the CanSat system are the competition deliverables. 
Table 2 describes the competition deliverables. 


Table 2. CanSat Deliverables for 2009 Competition. 


Deliverable 

Description 

Deadline 

Master Schedule 

Gantt chart to be used to track all progress toward 
completion of CanSat development. 

January 1 6, 2009 

Preliminary Design 
Review (PDR) 

A multi-disciplined technical review 
(teleconference) to ensure that the system under 
review can proceed into detailed design and can 
meet stated requirements. 

February 13, 2009 
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ESMD Space Grant 
Systems Engineering 
Paper 

A technical paper prepared for NASA that focuses 
on the systems engineering lessons learned by 
participating in the 2009 CanSat competition. 

March 2, 2009 

Hardware Review 

Review (teleconference or email) of the hardware 
selection and procurement to ensure successful 
completion of the CanSat. 

March 13, 2009 

Critical Design 
Review (CDR) 

A multi-disciplined technical review 
(teleconference) to ensure that the system under 
review can proceed into fabrication, integration, 
and testing. 

April 10, 2009 

CanSat (Quality Unit) 

Completed quality unit for system requirements 
verification. 

May 1,2009 

CanSat (Flight Unit) 

Completed flight unit to be delivered for 
competition. 

May 13,2009 

Flight 

Sounding rocket launch of CanSat in Amarillo, 
Texas. 

June 13, 2009 

Post Flight Review 

Assessment of flight operations and remote 
sensing data collected during mission. 

June 14, 2009 


2.1.2 System Constraints 

The CanSat must meet constraints set by the CanSat Competition as outlined in the 
CanSat Competition Design Guide [1] and chosen by the team (refer to Figure 12 in the 
Appendix for the Launch Vehicle Layout). The constraints set by the CanSat Competition Guide 
are much like the constraints that would be given to a design team by a customer, and are non- 
negotiable. These constraints are driven by real world conditions, such as payload volume on the 
launch vehicle, power of the launch vehicle, and existing communications infrastructure. 
Constraints chosen by the team are driven by bonus mission objectives outlined by the CanSat 
Competition Design Guide and dictate detailed design choices much more than the baseline 
design. The CanSat mission is admittedly simpler than many NASA missions, primarily because 
it does not travel in space, but the lessons learned from its design are directly applicable. The 
space industry is increasing interested in micro-craft that perform one function at little cost (cost 
being fuel, power, size, money) to the mission. The CanSat mission is a useful abstraction of the 
same problem at much lower risk. 
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2.1.3 Verification Planning 

A position on the design team allocated exclusively to make sure that all components of 
the CanSat comply with all constraints, design goals, compatibility requirements, etc. The 
Assembly, Integration and Testing engineer (AI&T) will oversee the manufacture and assembly 
of each component as well as dictate the order at which the subsystems are integrated into the 
Quality and Flight units. The AI&T position was also created to write and oversee all testing for 
the CanSat from the subsystem level to the master, full system test. It is the job of the AI&T 
engineer to relay test results the appropriate team members and keep track of the status of each 
component in the system. Concurrently, the AI&T engineer also acts as a consultant to each sub- 
system team with regard to system compatibility and ease of integration. For instance, if a 
design idea performs a task appropriately but integrates poorly with the CanSat, the AI&T 
engineer will use their knowledge of the full system architecture to suggest a superior interface 
for the sub-system with the rest of the CanSat. 

2.2 Requirements Analysis and Validation 
2.2.1 System Requirements 

Table 3 is a verification matrix that outlines the Master Requirements (MR) for the 
competition. The first column of Table 3 shows the unique requirement identification (i.e MR- 
1). The second column is a description of the requirement. The third column describes the 
rationale of the requirement. The fourth column details the priority of the requirement, or the 
impact that the requirement has on the system. The fifth column shows the “parents” or higher 
level requirements that the requirement is derived from. The sixth column shows the “children” 
or lower level requirements that have been derived from the stated requirement. The last column 
shows the Verification Method (VM) of the requirement (i.e. I - Inspection, T - Test, A - 
Analysis, and D - Demonstration; for a detailed explanation of these methods refer to Table 24 
in the Appendix). 
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Table 3. Master Requirements (MR) for CanSat. 


ID 

Requirement 

Rationale | Priority 

Parents 

Children 

VM 

MR- 

01 

CanSat shall not exceed 600g mass* 

Launch Vehicle 
Constraint 

High 

— 

SSD-02, EPS- 
04, DCS-02, 
MS-07 

1 

MR- 

02 

CanSat shall not exceed 279mm in length 

Launch Vehicle 
Constraint 

High 

— 

DCS -03 

• 

MR- 

03 

CanSat shall not exceed 72mm in 
diameter 

Launch Vehicle 
Constraint 

High 

— 


1 

MR- 

04 

The CanSat, while in flight configuration, 
shall have no protrusions that exceed 
dimensions outlined in MR-02, MR-03 

Launch Vehicle 
Constraint 

High 

— 

SSD-01, EPS- 
03, DCS-04, 
MS-06 

1 

MR- 

05 

Descent rate shall be between 2.2 m/s 
and 4.6m/s 

Mission 

Requirement 

High 

— 

DCS-09 

T,D 

MR- 

06 

During flight, CanSat shall transmit data at 
0.02Hz 

Mission 

Requirement 

High 

— 


T,D 

MR- 

07 

During flight, CanSat shall telemeter GPS 
position, number of satellites tracked, 
altitude by means other than GPS, and 
housekeeping telemetry at rate specified 
in MR-06 

Mission 

Requirement 

High 

— 

SSD-03, COM- 
03 

T,D 

MR- 

08 

Upon landing, CanSat shall switch 
communications to channel 0-000 with a 
57600 bit/sec data rate 

Mission 

Requirement 

High 

— 


T,D 

MR- 

09 

CanSat shall collect science data for 3 
hours 

Mission 

Requirement 

High 

— 

EPS-02 

T,D 

MR- 

10 

CanSat shall measure ground 
temperature via direct contact 

Mission 

Requirement 

High 

— 

SSD-04, MS- 
04 

T/D 

MR- 

11 

A time stamp shall accompany all 
temperature measurements 

Mission 

Requirement 

High 

— 

FSW-03 

T,D 

MR- 

12 

CanSat shall respond to unique telemetry 
requests with collected science data at 
least 10 times an hour 

Mission 

Requirement 

High 

— 

COM-04 

T,D 

MR- 

13 

The apogee altitude in meters and the 
landing coordinates shall be provided as 
part of the post flight review 

Mission 

Requirement 

High 

— 

SSD-05 

T 

MR- 

14 

The Cansat and GCS shall be less than 
$1000 (US) 

Cost Limit 

Low 

— 

SSD-06, COM- 
05, EPS-09, 
DCS-11, MS- 
09 

1 
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Table’4. Sensor System Design (SSD) Requirements. 


IlD 

Requirement 

Rationale 

Priority 

Parents 

Children 

VM 

Ea 

The SSD shall be no more than TBD in size 

Internal Space 
Constraint 

Medium 

MR-04 


1 

SSD- 

02 

The SSD shall have a mass no more than TBD 

Mass 

Constraint 




1 

SSD- 

03 

The GPS unit shall be accurate to within 10m 

Mission 

Requirement 

High 

MR-07 


■ 

i 

The method of determining temperature shall 
be accurate within 2 deg Celsius 

Mission 

Requirement 

High 

MR-10 


T 

SSD- 

05 

The altimeter shall be accurate within 4m 

Mission 

Requirement 

High 

MR-13 


T 

SSD- 

06 

The SSD shall cost less than TBD 

Cost Limit 

Medium 

MR-14 


1 


Table 5. Communications (Com) Requirements. 



Requirement 


CanSat communications shall utilize an 
COM- Aerocomm AC4790-200 transceiver 
01 configured to operate on an assigned 

channel 


Within ten (10) seconds of landing, the 
CanSat shall configure to meet MR-08, MR- 
12 


COM- GPS data shall be communicated in NMEA 
03 formatted data packets 


Rationale 


Mission 

Requirement 


Priority Parents Children VM 





























































Table 6. Electrical and Power System (EPS) Requirements. 


ID 

Requirement 

Rationale 

Priority 

Parents 

Children 

VM 

EPS- 

01 

The CanSat shall have external power 
control with confirmation of the 
cansat power state 

Mission 

Requirement 

High 

— 


l/D 

EPS- 

02 

The EPS shall provide power to all 
CanSat systems and components 
through launch, descent, and the 
post landing operation time or as 
needed 

Mission Time 
Requirement 

High 

MR-09 

EPS-05, EPS-06, 
EPS-07, EPS-08, 
DCS-07 

T 

EPS- 

03 

The EPS shall be no more than TBD 
size 

Internal Space 
Constraint 

Low 

MR-04 


1 

EPS- 

04 

The EPS shall have a mass less than 
TBD 

Mass Constraint 

Medium 

MR-01 


1 

EPS- 

05 

The EPS shall provide TBD Watts of 
power 

System 

Requirement 

High 

EPS-02 


U 

EPS- 

06 

The EPS shall provide power at TBD 
Volts 

System 

Requirement 

High 

EPS-02 


l/T 

EPS- 

07 

The EPS shall provide power at TBD 
Amps 

System 

Requirement 

High 

EPS-02 


l,T 

EPS- 

08 

Once on the ground, the EPS shall 
provide power by converting the 
energy of sunlight 

Bonus Mission 

Medium 

EPS-02 


l,T 

EPS- 

09 

The EPS shall cost less than TBD 

Cost Limit 

Medium 

MR-14 
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Table 7. Flight Software (FSW) Requirements. 


ID 

Requirement 

Rationale 

Priority 

Parents 

Children 

VM 

FSW- 

01 

FSW shall control DCS 

Bonus Mission 

Medium 

DCS-01 


A,T 

FSW- 

02 

FSW shall operate within 
constraints of selected 
microprocessor 

Size and Speed 

High 

— 

FSW-04, 

FSW-05, 

FSW-06 

A 

FSW- 

03 

FSW shall comply with all 
communications protocols 

Communication 

Standards 

Medium 

MR-11, 

COM-02, 

COM-03 


1 

FSW- 

04 

FSW shall be programmed in 
C 

Software/Hardware 

Constraint 

Medium 

FSW-02 


1 

FSW- 

05 

FSW shall not exceed 16KB 
when compiled to machine 
code 

Hardware Constraint 

High 

FSW-02 


l/A 
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FSW- 

06 


Data memory shall not 
exceed 1KB at any point in 
time 


Hardware Constraint 


High 


FSW-02 


■ - ■ ■ i — ■ 


Table 8. Descent Control System (DCS) Requirements. 


ID 

Requirement 

Rationale 

Priority 

Parents 

Children 

VM 

DCS- 

01 

CanSat shall autonomously navigate 
to within 10m of specified GPS 
coordinates 

Bonus Mission 

Low 

— 

FSW-01, DCS- 
05, DCS-06 

B 

DCS- 

02 

The DCS module shall NOT exceed 

200g 

1/3 of mass budget 

High 

MR-01 


I 

DCS- 

03 

The DCS module shall NOT exceed 
55.8mm in length 

20% of length 
budget 

Medium 

MR-02 


I 

DCS- 

04 

Deployable structures shall not 
protrude MR-02, MR-03 while stowed 

Launch Vehicle 
Constraint 

Medium 

MR-04 


I 

DCS* 

05 

The DCS shall determine and control 
direction of CanSat 

Bonus Mission 

High 

DCS- 

01 



DCS- 

06 

The DCS module shall be released 
within 1 meter of the ground 

Risk Mitigation 

Medium 

DCS- 

01 



DCS- 

07 

The DCS shall NOT exceed TBD 
Watts of Power 

Power Constraint 

High 

EPS-02 

DCS-08 



DCS components shall not exceed 
TBD VDC 

Voltage Constraint 

Medium 

DCS- 

07 


IjT 

DCS- 

09 

DCS operation shall not exceed 8 
minutes 

DCS constraint 

Medium 

MR-05 



DCS- 

10 

The DCS shall sustain 20 g's of shock 

Launch Vehicle 
Environment 

High 

MS-01 



DCS- 

11 

i 

1 The DCS shall cost less than TBD 

Cost Limit 

Medium 

MR- 14 


i 


Table 9. Mechanical System (MS) Requirements. 


UEJ 

Requirement 

Rationale 

Priority 

Parents 

Children 

| VM | 

H 

CanSat shall sustain 20 g's of 
shock 

Launch Vehicle 
Constraint 

Medium 

— 


D 


CanSat shall safely carry all 
mission components 

Critical to Mission 
Life 

High 

MS-01 



Q 

Mechanical System shall deploy 
solar arrays for power 
generation 

Bonus Mission 

Medium 

EPS-08 

MS-06 

D,T 

MS- 

04 

Mechanical System shall deploy 
sensory equipment to collect 
science data 

Mission 

Requirement 

Medium 

MR-10 

MS-06 

D,T 
































































































MS- 

05 

Mechanical System shall 
jettison DCS module 

Safety, Risk 
Mitigation 

High 

DCS-06 

MS-06 

D,T 

MS- 

06 

CanSat shall achieve a ground 
configuration 

Accommodate 

MS-03 

High 

MR-04, MS- 
03, MS-04, 

MS-05, 


D,T 

MS- 

07 

Mechanical System and internal 
structure shall have a mass less 
than TBD 

Mass Constraint 

Medium 

MR-01 


1 

MS- 

08 

CanSat shall maintain 
reasonable internal 
temperature 

Safety, Risk 
Mitigation 

Low 

— 


T 

MS- 

09 

Mechanical System and internal 
Structure shall cost less than 
TBD 

Cost Limit 

Medium 

MR-14 
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2.2.2 Reliability, Maintainability, and Survivability 

Reliability of the flight unit will depend greatly on the testing and evaluation outlined in 
section 2.2.6. Maintainability is not of utmost importance due to the fact that the CanSat only has 
to perform a single flight lasting approximately three hours. Survivability will rely on the design 
changes made after testing. 

2.2.3 Electromagnetic Compatibility 

Strong signal strength and flawless microcontroller performance are crucial to completion 
of the mission. Therefore electromagnetic interference (EMI) has been taken into consideration 
throughout the design process. We replaced our original carbon fiber design with a fiberglass one 
after extensive research on carbon fiber’s radio signal blocking properties. 

Upon completion of the quality model extensive EMI testing will be conducted. Initially 
the CanSat will be tested without any artificial interference to ensure that its structure and 
components do not cause any kind of internal interference. Once the basic test is complete 
artificial sources of interference will be introduced. The CanSat will be tested in the lab placed 
inside a rocket similar to that used in the competition. This is to test if the rocket will cause any 
kind of physical interference with the GPS signal and data transmissions from the CanSat. Once 
any physical interference issues are worked out the final test will consist of a rocket launch. This 
is to ensure there are no problems keeping a GPS signal lock while in flight. In previous years 
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many teams had issues with loosing the signal during the high speeds of takeoff. We do not want 
to encounter these problems, therefore testing will be crucial. 

2.2.4 Human Engineering and Safety 

Most safety issues arise from the fact that CanSat construction primarily takes place 
within a machine shop. Saws, drills, and other tools pose potential safety hazards. Several 
precautions have been taken to reduce the risk of bodily injury. Every team member was required 
to take a safety course run by the head of the shop. Members were educated in proper use of 
tools and their safety features such as guards and kill switches. 

At the competition high altitude rockets and CanSats returning to earth are the major 
safety hazard. The Panhandle of Texas Rocket Society (POTROCS) will be on site to supervise 
this aspect of the project. POTROCS is a Tripoli affiliated prefecture #92 with members 
possessing National Association of Rocketry certifications ranging from Level 1 to Level 3. 

2.2.5 Producibility and Product Support 

Producibility is a major concern when designing the CanSat because it will be 
constructed by students with limiting machining experience. Proper functioning of the flight 
model will rely heavily on producibility. The design uses Common off the Shelf (COTS) 
components whenever possible. This minimizes the need for custom parts reducing both cost 
and assembly time. It also allows the team to do most of the construction themselves and reduces 
outsourcing. 

The CanSat will be extremely supportable. All of the microprocessor coding is done in C 
which most members are familiar with. It utilizes a slot modular product architecture that allows 
for broken or malfunctioning parts to be quickly and easily replaced. The ultimate goal is to 
make the CanSat supportable enough that if anything breaks at the competition it can be repaired 
onsite with little difficulty. 

2.2.6 Test and Evaluation 

Initial tests will consist of testing individual components in the lab. One of the most 
important component tests will be the ram-air parachute. It will be tested in the Virginia Tech 
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Open-Throat Wind Tunnel to gain a better understanding of its flight characteristics as well as 
tune the Proportional-Integral-Derivative (PID) controller. Once an adequate understanding of 
how each component works is obtained they will be integrated into the quality unit. This unit 
will then be tested in the lab as a single system to ensure that all systems are working together 
properly. 

Upon completion of the system test in the lab EMI testing as described in section 2.2.3 
and drop testing will begin. Initial drop tests will consist of dropping the CanSat from the third 
floor of an indoor atrium and timing it to ensure that the ram air parachute provides the proper 
descent rate. When the results are satisfactory drop tests will be conducted off an eight story 
building on campus. In these higher drops the Descent and Control (DCS) system will be tested. 
It will be programmed to land at specific GPS coordinates. 

After working out the bugs in the drop tests the CanSat will be ready for the rocket test. 
This will simulate the exact circumstances of the competition launch. Every system will be 
tested simultaneously. A successful rocket launch will verify that the CanSat has met its system 
requirements and is ready for competition flight. 

2.2.7 Integrated Diagnostics and Transportability 

The “housekeeping telemetry” bonus mission will take care of integrated diagnostics. It 
will consist of sensors placed throughout the CanSat to monitor its overall health. The sensors 
will measure temperature of various parts, voltages, forces exerted upon the can, and anything 
else essential to the survival of the CanSat. 

Transportability will not be a major issue with the CanSat. It is small and compact in the 
first place and will be transported folded up in its launch configuration. This allows the outer 
shell to protect the internal components from damage. The team will be driving to the 
competition so the risk of damage during airline travel will be avoided. 
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2.3 Functional Analysis and Allocation 

Functional Analysis and Allocation is an essential initial step in the design and synthesis 
of a complex system such as the CanSat. Before decomposing a system into subsystems, the 
functions of the original system as a whole must be understood. A valuable preliminary tool is to 
consider the system as a “black box” and outline only the inputs and outputs. This technique is 
shown in Figure 3 for the CanSat project. By starting with a completely blank concept of the 
system, the team is better able to pursue all viable ideas after functional analysis has concluded. 
The next logical step in this method is to decompose the “black box” into several main functions. 
At this stage, it is still important to avoid limiting the final design with the functions; however, 
predetermined constraints may be incorporated. To achieve higher detail for complex systems, 
this method could be repeated for each function introduced in Figure 3 until a sufficient 
description has been synthesized. With this method, the CanSat functions are organized by their 
relation to the overall system’s external interactions, but not necessarily to the system’s Concept 
of Operations. Furthermore, functions that do not have a direct impact on inputs and outputs but 
are still critical (such as structural support) will not arise in this functional analysis method. 
Therefore, it is beneficial to use multiple techniques to ensure the system has been analyzed from 
all perspectives. 
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Figure 3: Functional Analysis: Input/Output Method. 
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This is not the only method by which a function can be decomposed, however. Another 
technique is to look at the system in terms of time. For this method, it is more beneficial to start 
with the system already divided into major blocks; so it is necessary to already have a Concept of 
Operations defined. This step should also use large, general divisions and not attempt to solve 
the problems, but merely describe them in a time flow manner. The second step of this 
technique is to decompose each of the primary functions into their own Functional Flow Block 
Diagrams (FFBD). This process can be iterated until the precision of the functions has reached a 
satisfactory level. Figure 4 shows the entire CanSat top level FFBD as well as the first 
decomposition of function 6.0 (Generate/Supply long term power). For this function, one 
decomposition is sufficient and the next stage, functional allocation, can begin. 


Top Level 


1.0 


2.0 


3.0 


4.0 


54) 


6.0 


7.0 


8.0 


Protect Internal 

> 


> 

Autonomously 

-> 

Pveleaje 

-> 

Upright CanSat 

■> 

Generate/ Supply 

-> 

Collect Temp. 

-> 

Transmit 


Component* 




amve at location 


Parachute 


chassis 


long-term power 


and system Data 


Collected Data 


(Structural) 




(DCS) 


(Mechanical) 


(Mechanical) 


(Electrical) 


(Electrical) 


(Electrical) 



Second Level - 5.0 Generate/Supply Long Term Power 



Figure 4: Functional Analysis: Time Flow Block Method 

Once the functions are generated and organized using both the FFBD and Input/Output 
methods, the team now has sufficient knowledge to effectively allocate the functions and sub- 
functions into sub-systems. By using both methods sub-system divisions can be created more 
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effectively by the consideration of both the physical proximity (one function relies on another for 
input) and time proximity (one function cannot start until the other has completed). For the 
CanSat project, the effects of both methods are evident. For the Electrical major sub-system, 
functions were allocated based on their reliance on the generation and storage systems for power 
(thus all functions that have an input of power are allocated to or interface with the electrical 
sub-system). For the minor sub-system of long-term energy generation, however, the sub- 
functions were allocated by time since each had to wait for or relied on the previous to complete. 
Figure 5 outlines the system divisions for the CanSat project. 


Major Sub- 
System Level: 


Minor Sub- 
System Level: 


System Level: 


CanSat 


Mechanical 


— Upright Landing 


Parachute 

Release 


Solar Panel 
Deployment 


Descent Control 


Electrical 







Autonomous 

Control 


Communitcations 






Speed Control 


Data Aquisistion 






Parachute 

Deployment 


Power 

Distribution and 
Generation 


Structural 


Component 

Protection 


Component 

Support 


Temperature 

Sensor 

Deployment 


Figure 5: System Divisions and Allocation 

2.4 Synthesis 

2.4.1 Commercial-Off-The-Shelf (COTS) vs. Developmental Items (DI) 


COTS items are defined as either software or hardware, that are ready-made and 
available for sale, lease, or license to the general public. COTS items are advantageous to any 
design project, especially CanSat, due to the financial savings they provide from general testing 
and maintenance of the product. The only testing needed with a COTS item is the interaction 
between the COTS product and the other systems within the design. The COTS item’s 
functionality has already been solidified through the vendor’s development of the product and 
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thus does not require testing concerning its operation. However, the major disadvantage to any 
COTS item is its limiting nature to the design. This is especially true concerning future changes 
of a design. To change a design, a team is now constrained and must change around the COTS 
item which can present a conflict to the overall efficiency and perhaps completion of the design. 

COTS items reduce the overall system development cost and development time of a 
design project. Eliminating the need for developing new systems that could require many trial 
and errors further helps reduce the possibility of failure in the project. This is because a team 
can better prepare for potential difficulties in a design be catching them earlier before 
competition. Because of these advantageous characteristics, this year’s CanSat team has taken 
certain key components necessary for the completion of mission objectives, and researched 
certain COTS items to be utilized for them. This is especially true concerning the parachute and 
servo needed for the autonomous landing bonus mission this year’s team has decided to 
undertake. Because of the team’s inexperience all together concerning autonomous landing, the 
more COTS items used for the descent control system leads to a more simplified and thus a more 
approachable design. 

Though there are many advantages to the use of COTS items, disadvantages can also 
arise. A reliance on COTS products can lead to problems with the overall systems integration of 
the design. This problem can lead to a dependence on third party vendors to replace certain 
components. This could be disadvantageous because the need for components adds to the cost, 
but time, counteracting the immediate advantages COTS items presented. This proved to be a 
major problem with the teams from the past two years. For example, because of an inefficient 
time allotted to the integration of systems, the team from two years ago (2006-2007 CanSat 
Team) was left with the need to pay for a hundred dollar overnight shipping bill for a camera 
only costing ten dollars to the competition site. To reduce this dependence, a balancing in the 
use of COTS items and DIs are essential not only to provide for a more simple design but also 
prevent such dependence and see the full advantages that COTS products incorporate. A 
comparison of COTS items used between the three teams from the past three years can be seen in 
tables three through five. Table 10, Table 11, and Table 12 lists the team’s use of COTS items 
and DIs over the past three years of participation in the competition. 
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Table 10. COTS vs. DI (2006-2007 Competition). 


COTS 

Servos 

Microcontroller 
Structural 1 
Digital Cameras 


_DI 

Release Mechanism 
Ram-air Parachute 
Camera Controller 


Batteries 


Arduino (Open - Source) Software 
Communications 


Table 11. COTS vs. DI (2007-2008 Competition). 


COTS 

DI 

Servos 

Release Mechanism 

Microcontroller 

Drilling Tool (Bonus Mission) 

Parachute 

Structural Components (Outer Shell) 

Cameras 

Software 

Batteries 

Communications 


Table 12. COTS vs. DI (2008-2009 Competition). 


COTS 

DI 

Servo 

Module Release Mechanism 

Microcontroller 

Partition Bracket 

Arduino (Open - Source) Software 

Payload Partitions 

Batteries 

Descent Control Software (PID Controller) 

Communications 

Solar Panel Doors Release Mechanism 

Remote Sensing Sensors 

Ram-air Parachute 

Solar Panels (Bonus Mission) 


2.4.2 Open Systems Architecture 

The Open System Joint Task Force (OSJTF) defines an open system architecture as “a 
system that implements sufficient open specifications for interfaces, services, and supporting 
formats to enable properly engineered components to be utilized across a wide range of systems 
with minimal changes, to interoperate with other components on local and remote systems, and 
to interact with users in a style that facilitates portability” [3]. This also implies that open system 
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architecture is essentially any layered structure or configuration in which a system can be 
distributed, so that each layer can be implemented without affecting the implementation of other 
layers. Furthermore, any changes needed to the system can be performed at any given layer 
within the structure. The CanSat’s design for the upcoming competition incorporates an overall 
modular design providing for an open systems architecture and thus lead to a more efficient 
integration of each system within the CanSat. 

The modular design developed by the mechanical team facilitates partitioning the CanSat 
into three sections with a central spinal column between each partitioning. The three sections 
allow for easy movement and placement of electronic parts exhibiting an open system 
architecture within the CanSat. This central spinal column allows space for wires providing a 
distribution of power to the various subsystems as needed. Because of this spinal column, each 
subsystem can be freely moved to any part of the CanSat and still be provided with power. 
Essentially, the CanSat structure does not dictate where each electronic part has to go, giving 
freedom to the design and easy maintenance to each part. This modular design can best be seen 
in Figure 6. 

•' • 

Figure 6. CanSat Modular Design. 

2.4.3 Reuse 

A major advantage in any design project is experience. Experience provides a team with 
essential information on components that work, but more importantly, components that do not 
work. The advantage to reusing certain components in a design is the development time. Having 
participated as a team for the past two years in the CanSat competition provides us with this 
opportunity. 
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Due to this year’s goal of implementing an autonomous landing system, the team is not 
able to reuse certain important components that have proved to be essential in previous year’s 
designs. However, one physical component that could be reused is the ram air parachute due to 
its stability in descent. The use of servos is another component that has proved to be essential in 
the design and will be implemented in the CanSat’s autonomous landing. Reusing components 
are not limited to physical components however because certain ideas can be reused. One 
important idea that is being reused is the position the CanSat will be in upon landing. A 
sideways configuration proved to be most efficient and has thus been implemented for this year’s 
design. 


2.5 Systems Analysis and Control 
2.5.1 Trade Studies 

The first trade study performed was for the Global Positioning System (GPS) receivers. 
The functional divisions involved in the trade study were the Electrical and Computer 
Engineering (ECE) Team and the Descent Control System (DCS) Team. The GPS receiver is 
used to determine the position and direction of the CanSat from the landing zone. The selection 
matrix shown in Table 13 was used to determine the GPS receiver for the CanSat system. 


Table 13. Selection Matrix for GPS Receivers 




Concept 



(Reference) 




Parallax GPS 

MN1010 GPS 

Selection Criteria 

Weight 

Rating 

Weighted Score 

Rating 

Weighted Score 

COTS 

15% 

3 

0.45 

3 

0.45 

Accuracy 

25% 

3 

0.75 

4 

1 

Size 

20% 

2 

0.4 

4 

0.8 

Mass 

15% 

3 

0.45 

4 

0.6 

Power Consumption 

15% 

3 

0.45 

3 

0.45 

NMEA Standard 

10% 

3 

0.3 

3 

0.3 


Total Score 


2.8 


3.6 


Rank 


2 


1 


Continue? 


No 


Develop 
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From Table 13, it is clear that the MN1010 GPS receiver has a better performance than 
the Parallax GPS receiver. The only criteria where the Parallax GPS receiver has better 
performance than the MNIOIO GPS receiver is the team’s previous experience. 


The Parallax GPS receiver has been used for the past two years by the CanSat Team and 
has had limited success. In 2007, the Parallax GPS receiver performed well during testing but 
was not proven to work in competition due to a failure with the communications system. In 
2008, the Parallax GPS receiver performed as expected during testing but had a failure before 
prelaunch due to poor wiring and soldering. Therefore, the team has selected the MNIOIO GPS 
receiver for further study and testing. 

The next trade study performed was to determine a method for measuring the ground 
temperature via direct contact. The functional division directly responsible for conducting this 
trade study was the ECE Team. Table 14 shows the selection matrix used to determine the 
ground temperature method. From Table 14, it is clear that the thermocouple method is the 
preferred method for determining the ground temperature via direct contact. 


Table 14. Selection Matrix for Ground Temperature Sensor. 



Concept 

(Reference) 



Thermocouple 

Infrared Temperature Sensor 

Thermistor 

Selection Criteria 

Weight 

Rating 

Weighted Score 

Rating 

Weighted Score 

Rating 

Weighted Score 

COTS 

15% 

3 

0.45 

3 

0.45 

3 

0.45 

Low Cost 

10% 

3 

0.3 

1 

0.1 

3 

0.3 

Low Mass 

10% 

4 

0.4 

2 

0.2 

3 

0.3 

Small Volume 

15% 

4 

0.6 

3 

0.45 

2 

0.3 

Durability 

20% 

4 

0.8 

3 

0.6 

3 

0.6 

All Inclusive 

10% 

3 

0.3 

3 

0.3 

2 

0.2 

Accuracy 

20% 

3 

0.6 

3 

0.6 

2 

0.4 


Total Score 



3.45 


2.7 


2.55 


Rank 



1 


3 


2 


Continue? 



Develop 


No 


No 


The next trade study was to determine a close-range sensor method for the CanSat. The 
close range sensor is used to determine when the CanSat is near the ground. The functional 
divisions involved in the trade study were the ECE Team and the DCS Team. Table 15 is the 
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selection matrix used to determine which method the CanSat would use for determining when it 
is close to the ground. 


Table 15. Selection Matrix for Close-Range Method. 




Concept 



(Reference) 





Ultrasonic 

Infrared 

Triangulation Based 

Selection Criteria 

Weight 

Rating 

Weighted Score 

Rating 

Weighted Score 

Rating 

Weighted Score 

COTS 

10% 

3 

0.3 

3 

0.3 

2 

0.2 

Large Range 

25% 

3 

0.75 

3 

0.75 

2 

0.5 

Low Mass 

20% 

3 

0.6 

3 

0.6 

3 

0.6 

Small Volume 

15% 

3 

0.45 

3 

0.45 

3 

0.45 

Experience 

15% 

3 

0.45 

2 

0.3 

2 

0.3 

Low Cost 

10% 

3 

0.3 

2 

0.2 

2 

0.2 

Needs Reference Distance 

5% 

3 

0.15 

3 

0.15 

2 

0.1 


Total Score 


3 


2.75 


2.35 


Rank 


1 


2 


3 


Continue? 


Develop 


No 


No 


Table 15 determined that both ultrasonic and infrared methods have good performance 
and that both should be further researched and tested to determine the best option for a close- 
range sensor. Thus, the team selected both the ultrasonic and infrared sensors for further study. 

The next trade study performed was to establish CanSat’ s method for altitude 
determination. The functional divisions involved in the trade study were the ECE Team and the 
DCS Team. Table 16 is the selection matrix for the altitude determination method. 
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Table 16. Selection Matrix for Altitude Determination Method. 




Concept 



(Reference) 





Digital Barometric Pressure 

Mechanical Pressure 






Sensor 


Sensor 

Laser Altimeter 

Selection 







Weighted 

Criteria 

Weight 

Rating 

Weighted Score 

Rating 

Weighted Score 

Rating 

Score 

COTS 

15% 

3 

0.45 

3 

0.45 

2 

0.3 

Low Power 

20% 

3 

0.6 

3 

0.6 

2 

0.4 

Low Mass 

20% 

4 

0.8 

2 

0.4 

2 

0.4 

Small Volume 

15% 

3 

0.45 

2 

0.3 

2 

0.3 

Experience 

15% 

4 

0.6 

3 

0.45 

3 

0.45 

Low Cost 

10% 

3 

0.3 

2 

0.2 

2 

0.2 

Needs 

Calibration 

5% 

3 

0.15 

3 

0.15 

3 

0.15 


Total 








Score 


3.35 


2.55 


2.2 


Rank 


1 


2 


3 


Continue? 


Develop 


No 


No 


Table 16 shows that the altitude determination method with the best performance is the 
barometric pressure sensor. The 2007 and 2008 both CanSat teams used a barometric pressure 
sensor for determing altitude. In 2007, the barometric pressure sensor performed well during 
testing but was not proven to work in competition due to a failure with the communications 
system. In 2008, the barometric pressure sensor worked perfectly in the competition and 
transmitted accurate atmospheric pressure data back to the ground station for analysis that was 
presented in the post- flight debrief. Due to last year’s success and the results from the selection 
matrix, the team has selected the barometric pressure sensor for determining altitude during the 
descent of the CanSat. 


The ECE Team the performed the trade studies for the power system. Both the 2007 and 
2008 CanSat Teams used one lithium ion battery to power all the systems on the CanSat. The 
2007 and 2008 CanSats required to be powered for at least one hour. The 2009 CanSat will 
require more than three hours of power. Table 17 shows the selection matrix used to determine 
a power system that would be able to support a three hour mission. 
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Table 17. Selection Matrix for Power System. 




Concept 



(Reference) 







Lithium Polymer 
Battery 

Nickel Metal 
Hydride Battery 

Solar Panels 

Solar Panel with 
UltraCap 

Solar Panels with 
Lithium Polymer 
Battery 

Selection 

Criteria 

Weight 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

COTS 

10% 

4 

0.4 

3 

0.3 

3 

0.3 

2 

0.2 

4 

0.4 

No Additional 

Mechanisms 

Required 

10% 

4 

0.4 

4 

0.4 

3 

0.3 

3 

0.3 

3 

0.3 

Low Mass 

15% 

3 

0.45 

2 

0.3 

3 

0.45 

2 

0.3 

3 

0.45 

Experience 

5% 

3 

0.15 

3 

0.15 

2 

0.1 

1 

0.05 

2 

0.1 

Large Voltage 
Range 

15% 

« 3 

0.45 

3 

0.45 

3 

0.45 

3 

0.45 

3 

0.45 

Large Current 












Range 

20% 

3 

0.6 

2 

0.4 

2 

0.4 

2 

0.4 

3 

0.6 

Large Power 
Capacity 

15% 

3 

0.45 

2 

0.3 

2 

0.3 

2 

0.3 

3 

0.45 

Solar 












Powered 

10% 

1 

0.1 

1 

0.1 

5 

0.5 

4 

0.4 

4 

0.4 


Total 

Score 


3 


2.4 


2.8 


2.4 


3.15 


Rank 


2 


4 


3 


5 


1 


Continue? 


No 


No 


No 


No 

Develop 


Table 1 8 determined that the solar panel and lithium ion battery combination performed 
the best. Additionally, a selection matrix specific to the solar panels performance was performed 
by the ECE and Mechanical Engineering (ME) Teams to determine the optimization of the 
power system. Table 18 shows the selection matrix for the solar panels. Table 18 determined 
that the best optimization for the power system was to use rigid panels. 
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Table 18. Selection Matrix for Solar Panels. 




Concept 



a) Flexible Panel 

b) Rigid Panel 

c) Rigid Supported by 
Flexible 

Selection Criteria 

Weight 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

Rating 

Weighted Score 

Weight 

20% 

3 

0.6 

5 

1 

4 

0.8 

Mounting Flexibility 

20% 

2 

0.4 

3 

0.6 

3 

0.6 

Durability 

10% 

5 

0.5 

2 

0.2 

2 

0.2 

Complexity of Mount 

10% 

4 

0.4 

4 

0.4 

2 

0.2 

Volume / Surface Area 
Required 

40% 

2 

0.8 

4 

1.6 

3 

1.2 


Total 

Score 


2.7 


3.8 


3 


Rank 


3 


1 


2 


Continue? 


No 


Develop 


No 


The DCS Team performed the trade studies for the descent control hardware. The main 
system driver for the descent control hardware was the ability to navigate the CanSat to a 
specified set of landing coordinates. Table 19 shows the selection matrix used to determine the 
descent control hardware for the CanSat. 


Table 19: Selection Matrix for Descent Control Hardware. 


Criteria/Options 

Ram-air 

parachute 

Deployable 

Wings 

Ram-air 
with a 
Fan 

Round 

Parachute 

Paraglide 
with a Fan 

COTS Product 

Yes 

No 

No 

Yes 

No 

Low Mass 

Yes 

No 

No 

Yes 

No 

Experience 

Yes 

No 

No 

Yes 

No 

No Propulsion 

Yes 

Yes 

No 

Yes 

No 

Controls direction 
of CanSat 

Yes 

Yes 

Yes 

No 

Yes 


Table 19 shows that the best performance for descent control hardware that will control 
the direction of the CanSat is the ram-air parachute. In 2007, the CanSat team attempted 
controlling the direction of the CanSat with a ram-air parachute and the design showed 
promising results. In 2008, the CanSat team was more cautious and decided to use a standard 
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round parachute and focus on the primary requirements of the CanSat design. Thus, the team has 
selected the ram-air parachute as their primary descent control hardware and the round parachute 
as a backup. 

The last trade study performed by the ME and DCS teams was to determine the DCS 
actuator. Table 20 describes the options and criteria used to determine the actuator with the best 
performance. 


Table 20: Selection Matrix for CanSat Actuator. 



Metal Geared Servo 

Linear Actuators 

Nylon Geared Servo 

Selection 

Criteria 

Weight 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

Rating 

Weighted 

Score 

COTS Item 

25% 

3 

0.75 

2 

0.5 

3 

0.75 

Strength 

30% 

3 

0.9 

3 

0.9 

1 

0.3 

Low Mass 

20% 

2 

0.4 

1 

0.2 

3 

0.6 

Complexity 

15% 

3 

0.45 

1 

0.15 

3 

0.45 

Volume 

10% 

2 

0.2 

1 

0.1 

1 

0.1 


Total 

Score 


2.7 


1.85 


2.2 

Rank 


1 


3 


2 

Continue? 


Develop 


No 


No 


Table 20 confirms that the metal geared servo has the best performance of the three 
options. Metal geared servos come in a wide variety of sizes, torque, masses, and brands. The 
team will be required to purchase and test multiple types so that the metal geared servo is 
optimized. 

Additional selection matrices performed were Table 21 for the material selection and 
Table 22 for the up-righting system. 
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Table 21. Material Selection Matrix for CanSat Interior and Exterior. 



Carbon Fiber 

G10 Fiberglass 

6061 Al Alloy 

Wood 

Selection Criteria 

Rating 

Score 

Rating 

Score 

Rating 

Score 

Rating 

Score 

Strength 

30% 

5 

1.50 

5 

1.50 

4 

1.20 

2 

0.60 

Price 

15% 

2 

0.30 

3 

0.45 

4 

0.60 

5 

0.75 

Workability 

10% 

3 

0.30 

3 

0.30 

4 

0.40 

5 

0.50 

Experience 

5% 

3 

0.15 

5 

0.25 

4 

0.20 

4 

0.20 

Fatigue Resistance 

20% 

5 

1.00 

5 

1.00 

2 

0.40 

1 

0.20 

EM safe 

20% 

1 

0.20 

4 

0.80 

3 

0.60 

4 

0.80 

Total Score 

3.45 

4.30 

3.40 

3.05 

Rank 

2 

1 

3 

4 

Continue? 

No 

Develop 

No 

No 


Table 22. Selection Matrix for Up-righting System. 



Weighting 

Spring 

loaded 

hinge 


Three legged 
up righting 


Two legged 
up righting 




Rating 

Score 

Rating 

Score 

Rating 

Score 

Up righting force 

35% 

2 

0.7 

3 

1.05 

3 

1.05 

Ability to correct 
inverted landing 

35% 

2 

0.7 

4 

1.40 

3 

1.05 

Weight 

20% 

4 

0.8 

1 

0.2 

3 

0.6 

Ease of construction 

10% 

4 

0.4 

1 

0.1 

3 

0.3 

Total 

100% 


2.60 


2.75 


3. 

Develop 



No 


No 


Yes 


2.5.2 Budget Management 

The Virginia Tech CanSat Team received funding for the 2008 - 2009 academic year from 
BAE Systems, Inc. in Manassas, Virginia. A proposal for $3,000 to BAE Systems, Inc. was 
completed in September and was accepted in October. The total expenses for the 2008 CanSat 
team and the projected expenses for the 2009 CanSat team are described on pages 28 and 29. 
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2008 Summary: 


Flight Unit: 


Mechanical/Structural Subsystem: 

$104.87 

Electrical & Computing: 

$420.86 

Power: 

$35.90 

Recovery: 

$15.95 

Subtotal: 

$577.58 

Ground Station and Testing: 

Ground Station Equipment: 

$284.80 

Testing: 

$131.00 

Subtotal: 

$415.80 

Travel Costs for Competition: 

Hotel: 

$840.00 

Vehicle Rental & Gas: 

$660.00 

Subtotal: 

$1,500.00 

Total Cost of CanSat Project: 
2009 Projections: 

$2,493.38 

Flight Unit: 

Mechanical/Structural Subsystem: 

$100.00 

Electrical & Computing: 

$450.00 

Power: 

$150.00 

Recovery: 

$200.00 

Subtotal: 

$900.00 

Ground Station and Testing: 

Ground Station Equipment: 
Backup Supplies: 

$250.00 

$150.00 


$150.00 


Testing Equipment: 


$200.00 


Subtotal: $600.00 

Travel Costs for Competition: 

Hotel: $840.00 

Vehicle Rental & Gas: $660.00 

Subtotal: $1,500.00 

Projected Cost of CanSat Project: $3,000.00 


2.5.3 Data Management 

The data management for the CanSat is formatted by competition requirements. 
“Requests for science data packets shall be generated by the competition science Ground Control 
Station (GCS)” (CanSat Competition, 2008). The commands shall be addressed for specific 
CanSats via the CanSat identification (ID) number. The science data packet request command 
shall be an ASCII text string formatted as shown in Table 23. 


Table 23: Science Data Packet. 


# of Char* 

2 

2 

1. 

6 

1 

7 

1 

8 

1 

5 

1 

5 

1 

40 

1 

Data 

SP 

<1D> 

T 

<TIME> 

N 

<LAT> 

W 

<LON> 

H 

<ALT> 

C 

<TEMP> 

U 

<HT> 

/ 


^Number of characters 


The following list describes the abbreviations and acronyms used in Table 23. 

1 . SP - 1 st character and start of package (stands for Science Package), (cc)* 

2. <ID> - unique CanSat ID (##)** 

3. T - 5 th character (stands for time), (c) 

4. <TIME> - time tag, (hhmmss)*** 

5. N - 12 th character (stands for North), (c) 

6. <LAT> - latitude, (##.####) 

7. W - 20 th character (stands for North), (c) 

8. <LON> - longitude, (###.####) 

9. H - 29 th character (stands for Height), (c) 

10. <ALT> - altitude in metes, (###.##) 

1 1 . C - 34 th character (stands for Celsius), (c) 

1 2. <TEMP> - temperature, (##.###) 

13. U - 40 th character (stands for start of housekeeping telemetry), (c) 

14. ; - data package terminated 

* “c” stands for a letter character 
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** “#” stands for a number (0 - 9) 

*** “jj” stands for hour, “m” stands for minute, and “s” stands for second (all numbers) 


Figure 7 illustrates the method in which multiple CanSat teams will be able to transmit 
science data packets during the mission. The Mission Data Relay Configuration consists of a 
weather balloon that has a data relay attached to it, CanSats from all the teams, the ground 
stations for all the teams, and the central ground station. 


Cansat Rads Setup 
System ID 0x00 
Channel Set 0 
Chen net 0x00 


a 


Cansat 01 


CD 

Cansat 02 



Figure 7: Mission Data Relay Configuration. 


Figure 8 shows the mission timeline for the science data collection. After landing, the 
CanSats will transmit science data for one hour to the relay weather balloon which will relay data 
to the team ground stations. After one hour has passed on the ground, CanSats will be able to 
transmit the optional landing image data for one hour. After two hours have passed on the 
ground, teams will transmit the science data packet as described in science data collection (2) 
part of Figure 8. 
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2.5.4 SE Master Schedule 


The SE Master Schedule is a required deliverable of the CanSat Competition. For clarity, 
the SE Master Schedule is organized by functional division (i.e. Systems, Descent Control 
System, Electrical and Power System, and Mechanical System). Refer to the Appendix to view 
the Gantt charts of the SE Master Schedule. 

3 Transitioning Critical Technologies 

3.1 Mechanical Engineering Subsystem 

3.1.1 Criteria 

The CanSat project requires the utilization of many items that are either not readily 
available or are not optimum in terms of cost, weight, or performance. Therefore, the designs 
and technologies to implement these functions must be developed or modified. From the 
mechanical side, this usually focuses on the modification of existing technologies or products to 
satisfy the requirements. The main concerns in this case are that the design is feasible to 
fabricate and that the new product does not exceed or dramatically change (in which case the 
results of the modification would be unpredictable) the loading on the original part. From the 
structural perspective, this process may center more on the selection of the optimum material as 
it is very unlikely that anything resembling the required structure is being produced. In this case, 
the primary concerns are the mechanical performance of the technology as well as its interactions 
with other systems. An excellent illustration of the importance of analyzing the effects across 
systems occurred with the structural team this year. Initially, carbon fiber was chosen as the best 
combination of weight, cost, and strength. However, upon further analysis (and thanks to some 
members with remote control plane experience) it was realized that extensive use of carbon fiber 
could shield or significantly reduce the range of the radio system. With this new information, the 
team resumed research into other materials and selected G10 fiberglass due to its excellent 
mechanical performance and no significant radio disruption. 

3.1.2 Activities and Risks 

To describe the Critical Technology Transitioning methodology the team implemented, I 
will present our process in terms of the mechanical team’s selection and development of the 
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release for the solar panel doors. Initially, the team explored the use of a COTS item (such as a 
positive lock pin) to simplify the process. Although several promising products were found, 
when the team tried to create designs around them it was determined that they required a 
disproportionate amount of volume and weight of the can. Furthermore, all products would have 
required significant modifications to the current designs (and thus necessitate more integration 
time). From this, the team decided to focus on new technology that would work in unison with 
the existing bulkheads, mounts, and the solar panels themselves. From here, we determined the 
major potential risks: unit jamming, releasing prematurely, and interfering with other 
components. With these in mind, the team turned to choosing a COTS component to be the 
center of the design and selected a solenoid due to its very low mass and reasonable size. While 
the team did not have extensive experience with solenoids, we did know from our previous 
year’s competition that even small shear forces on the plunger could result in the solenoid 
jamming. Since our goal was to minimize this risk, we designed the mechanical aspect of the 
release to support the plunger and increase the horizontal displacement of the release pin while 
keeping the solenoid in its optimum force range as shown in Figure 9. 



Figure 9. Mechanical Critical Technology Transitioning - Solar Door Release Mechanism. 

While this mitigates the risk of the release jamming to an acceptable level, it does nothing 
to alleviate the second major risk that is for the unit to release prematurely. To address this, we 
first determined that the most likely way for this unwanted release to occur was by a force or 
vibration that would cause the plunger to drop. Although testing is required to confirm our 
plans, we currently think that the shear forces in the door pin will create a sufficient amount of 
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friction to keep the release locked. If this is not the case, the team will add a plunger restoring 
spring to ensure that the system stays locked until desired. Finally, this design addresses the 
space and mass requirements we set so that it does not interfere with other components. One of 
the key features of this design, the supported lever arm, not only improves the mechanical 
durability of this design, but it also allows the team to place the solenoid below the solar arrays 
and firmly attached to the can central structure and thus reduce interference and improve 
strength. With the critical technologies of the solar release now designed and transitioned, we 
can now focus on fabrication, integration, and testing of this component. 

3.2 Electrical and Computing Engineering (ECE) Subsystem 

3.2.1 Criteria 

This CanSat electrical system is required to interface with many different components. In 
order to collect and transmit the required data the minimal system had to include GPS, altimeter, 
processor, transceiver, and temperature sensor. However, because we chose to pursue both an 
autonomous landing and solar power missions the electrical system was expanded to include 
components needed to collect additional data and add additional outputs to control the 
autonomous landing system. Most of the system is made up of COTS components including the 
processor, altimeters, GPS and temperature sensor. 

3.2.2 Activities 

Due to the nature of the power system required to implement the autonomous landing 
and the solar power missions a COTS power system was not available and one had to be 
developed (Refer to Figure 13 in the Appendix). The power system requires a battery, to provide 
power during the autonomous landing, and solar panels to provide power while on the ground. 
While the battery needed was a COTS lithium polymer battery with an output of 7.2V, a 
comparable solar panel with a similar output was not available off the shelf that would fit within 
the mechanical structure of the CanSat. Because a COTS solar panel was not available one ad to 
be developed from COTS materials. By using small rigid solar panels, shown in Figure 10, and 
combining them in series we were able to achieve the needed voltage and current levels to supply 
power to the electrical system while on the ground. 


34 



Figure 10: Solar Panel System. 

Another aspect of the power system needed to address the issue of different electrical 
system components requiring different voltage levels to power the devices. Some devices 
required a nominal voltage of 3V and others required a nominal voltage of 5V. By placing the 
limit of these two voltage levels, which are the most common for small electronics, we avoided 
having to use a different voltage regulator for each component. With this design only two 
voltage regulators are required one to regulate the 3V and one to regulate the 5V. 

3.2.3 Risks 

There are inherent risks associated with not using an entirely COTS power system. 
While most of the components of the power and electrical systems are COTS items the power 
system includes the solar panel design which is not. The risk of not using a COTS solar panel 
was outweighed by the customizability of using the individual panels in a way that custom fits 
within our system. In order to minimize the risk of the solar panel not working or not 
performing to the standards we have set, extensive testing will be done on the custom solar panel 
to ensure proper function. 

3.3 Descent Control Subsystem (DCS) 

3.3.1 Criteria 

The DCS is a system meant to provide controlled descent for the CanSat while 
autonomously guiding it to a predetermined target location. To complete this overall objective 
the DCS uses a combination of sensors and actuators to control the system. Because of the 
complex nature of the small autonomous system, the DCS team developed stringent criteria that 
will ensure the success of the system. By keeping the overall objective of the DCS in mind, the 
DCS team developed the three main criterions that will guide the design and development of the 
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DCS. The DCS must first be small enough to fit the CanSat payload and the two inch module 
allocated by the mechanical team to the DCS. Secondly, the DCS must minimize power usage. 
The last criterion is the DCS must function without propulsion. 

3.3.2 Activities 

Taking the above DCS criteria into consideration we were able to decide upon certain 
sensors and actuators that would best suit the CanSat. To minimize volume, power usage, and 
make the DCS independent of propulsion the team decided on using a metal geared servo. The 
servo will control deployable arms that will be attached to the ram air and thus control direction 
of the CanSat. We also decided on the sensors needed to provide the necessary data to the DCS 
to complete the fully controlled descent while still meeting the above criteria. We decided to use 
a barometric sensor for our altimeter while deciding to use a GPS to determine CanSat location. 
Because the competition requires telemetry data to be provided during descent we can minimize 
power usage by using barometric sensor and GPS for both DCS and telemetry functions. A 
sensor specific to DCS is the ultrasonic sensor for close ground detection from about 20 ft. from 
the ground. This sensor is meant to provide extra data in order to properly dislodge the DCS 
module before ground impact to avoid the ram air from being entangled with the CanSat and 
preventing base missions of the CanSat from being accomplished. 

3.3.3 Risks 

There are always inherit risks with any system being developed. One of the biggest risks 
related to the DCS is the unpredictability of the ram-air parachute. The ram air’s full 
deployment is essential to the success of controlling descent rate, which is a requirement of the 
CanSat. Having one cell of the ram air not inflate could cause the loss of the rigid wing needed 
to control such descent and thus cause the CanSat to descend to the ground at an uncontrollable 
rate and would result in the loss of the CanSat. With the addition of turning during descent due 
to autonomous control, descent rate can be even more unpredictable and thus fall out of the 
allowable requirement range provided by the competition. 

Risks are further presented with the additional mass and volume contributed by the DCS. 
These extra factors place further constraints on base features of the CanSat and thus could cause 
a better probability of failure concerning the base missions of the CanSat. 
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4 Integration of Systems Engineering Effort 

4.1 Expectation of Reviews and Frequency of Reviews 

The CanSat competition has three reviews; a Preliminary Design Review (PDR), a 
Hardware Review (HWR), and a Critical Design Review (CDR). These allow the team to inform 
the judges about what we have been working on and what direction our design is moving in. The 
preliminary design review’s purpose is to demonstrate that the team understands the rules, and is 
able to meet the mission requirements within the budget, time, and risk constraints. The PDR 
took place in February and the judges agreed that our design is sound and ready for further 
development. The hardware review is a more informal review that takes place in March to prove 
to the team’s mentor that hardware selection and procurement is leading the team to the 
successful completion of the CanSat. The critical design review is a multi-disciplinary technical 
review that takes place in May and allows the team to show the judges that we have a solid final 
design that is ready for production. 

4.2 Organization and Integration of Design Disciplines 

The design of the CanSat was organized by sub-system, as outlined in section 2.3, and 
illustrated in Figure 3, to facilitate greater efficiency in the design phase of the project and a 
better product through specialization of tasks. This team and system break-down worked as 
intended and the outcome was a strong design that should work well and is expected to be 
competitive in the long run. In the short run, this organization break-down creates an integration 
task more involved, but one that will ultimately improve the quality of the CanSat. 

It was with this foreknowledge that the CanSat was designed and the result was a 
modular structure that favored component integration. The design allows the team to assemble 
and test sub-system components off the main structure and then mate them quickly and easily to 
the main structure. As discussed earlier, a major facet of the design is an electrical spine that 
runs up the center of the CanSat allowing components to be attached and immediately access 
power wherever they are mounted. In addition, panels in the payload module of the CanSat that 
act as mounting plates for electrical and mechanical components can be slid in and out of 
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mounting brackets on either end of the module so components can be mounted to the plate with 
plenty of room for tools and hands, and then simply slid into place and anchored on the main 
structure. 

Software integration was also a strong consideration when choosing components for the 
computing sub-system. Software integration will be handled by the software engineers. 

Hardware was chosen to assist with software integration and components were chosen that 
already had native control libraries and were capable of running higher level code such as C and 
C++. Hardware integration will be fairly simple and overseen by the AI&T engineer who will 
direct wire routing and placement inside the payload module - yet another reason for the central 
electrical spine. 

5 Implementation Tasks 

5.1 Electrical and Computing Subsystem 

5.1.1 Proof of Concept 

The electrical and power system had several design goals. These goals were split up into 
electrical system goals and power system goals. The main electrical system goal was to collect 
all of the science data required to be transmitted back to the ground station and to use this data to 
control the autonomous descent system. The power system goal was to integrate a solar panel 
system into the mechanical design of the CanSat and provide continuous, reliable power to the 
electrical system. In order to design an overall system that would accomplish these goals the 
design was dispersed within the team so each goal could be focused on individually. The 
electrical system was designed by the electrical sub-team in conjunction with the descent control 
team in order to ensure that all the necessary sensors were included in the design to collect and 
transmit the data required for the science mission and control the autonomous landing system. 
The power system was designed by the electrical sub-team in conjunction with a subset of the 
mechanical team. Together they were able to design a solar power system that would fulfill the 
power needs of the electrical components and physically fit within the CanSat. 

5.1.2 Electrical System Software Development 

The electrical system is heavily dependent on software. The software to control the 
processor, sensors and transceiver was developed in the C language. By modifying and using 


38 


open source code provided by the component manufacturers we were able to communicate with 
all of our sensors and translate their data outputs into the information that we are required to 
transmit back to the ground station. By using these provided sections of code rather than 
developing an original code to accomplish the same task from scratch we are able to ensure that 
the code correctly communicates with the different components. The entire program will first be 
tested in sections, to ensure that each component individually is functioning correctly. Once we 
confirm that each section is working individually we will begin to test the program and the 
electronic system as a whole. 

5.1.3 Electrical Power System Development 

Once a couple of design concepts were developed for the solar power system some 
materials were ordered so we could do concept testing on them. One of the designs was to use 
sheets thin-film solar panels rolled up within the CanSat that would deploy upon landing. 
However, when we got the material and began testing it, it was found that the sheets were not 
pliable enough to be rolled tight enough to fit inside the CanSat. Then the second design idea of 
using multiple rigid solar panels and mounting them inside the CanSat was tested. A conceptual 
model was built to test this structure and it was found to be a viable concept. 

5.1.4 Electrical and Power System Testing 

The electrical and power system is composed of many individual sensors and other 
components; because of this it is very important to compartmentalize the testing procedure of 
this system. Each sensor and component will be tested individually before being integrated into 
the CanSat to ensure proper function. This testing of each component before it is integrated will 
greatly reduce and simplify the troubleshooting of the system once it is entirely installed and 
tested as a whole. Another design implementation that will greatly reduce the time and effort 
required in testing is the use of connectors between many of the components rather than 
soldering the components directly to the connective wires. This use of connectors will make it 
simple to remove a component for further individual testing or for replacement. 

After the concept of rigid panels was proven to be the most viable option the design was 
further developed. The panels will be assembled together and mounted within the structure of 


39 



the CanSat. The mechanical sub-team is developing a mechanism to control the opening of the 
solar panel bay doors. This mechanical system will be tested to ensure proper opening of the 
solar panel bay. Additional testing will be done on the solar panels themselves to test their 
construction and power output. Once the power output of the panels is confirmed the solar 
panels will be connected to the rest of the power system and the whole system will be tested 
under multiple temperature and sunlight conditions. It is important to test the power and 
electrical system in multiple temperature and sunlight environments because the high 
temperatures reached in the summer could have an effect on the electrical components and the 
amount of sunlight reaching the solar panels can greatly affect their power output. 

5.2 Mechanical Subsystem 

The implementation of each component of the CanSat can be classified into three 
categories: purchase, make, or reuse. For illustration purposes, I will continue with the product 
introduced in the Mechanical section of the Transitioning of Critical Technologies (Section 3), 
the Solar Door Release, we see that two of the implementation types are utilized. The solenoid is 
a purchased COTS item while the mount and lever system is a unique fabricated item. While 
each of these presents distinctive challenges to employ successfully, they both have the same 
basic goal: to reproduce the functions of our idealized design as accurately as possible. To 
ensure that this is the case the COTS solenoid needs to be tested to confirm that it meets the 
manufacturer’s specifications (or at least is sufficient for pulling the'door pin). For the fabricated 
unit similar tests must be conducted, however they are conducted in several phases. First, the 
team assembles the unit in a test rig to ensure the concept works (and this is repeated under 
various conditions to determine reliability). After we complete these tests successfully or make 
necessary changes, we assemble the component in the final unit and test again to ensure that 
there are no conflicts with the other systems in the can. 

The critical step in the implementation stage is designing the tests to accurately simulate 
(or are) the real conditions that the CanSat may experience. If the tests are not correct 
representations, then our confidence in the probability of success we found from the tests is low 
and the data we collected meaningless. For the Solar Deployment system, the primary potential 
causes of failure were determined to be landing on the door, vibrations, and the acceleration at 
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launch, apogee, and landing. Therefore, once the test unit is created, the team will focus on these 
situations. To ensure realism in the tests, the unit will be dropped for the tests analyzing the 
effects of door landings or shocks and launched in a rocket (or have launch vibrations simulated 
if possible) to test vibrations. By utilizing tests such as these, the team ensures that the result we 
obtain is robust and that we can be confident in the performance of the component. 

The realization of the design is of course the goal of the vast majority of projects, and 
standing at the front end of a project can seem like a daunting task. With the proper preparation 
and organization however, the implementation of the countless hours of work put into the project 
up to this point is quite straight forward. It is important to point out that while, typically up to 
this point project teams are divided into subsystem task groups, all task groups need to reconvene 
into a single unit, with their specialized perspectives on the implementation, for the overall 
process to run smoothly. For the CanSat project, the perspective on implementation brought to 
the table by the mechanical engineering group primarily concerns the verification of the physical 
integration of all the subsystem components. 

During integration, at the direction of the AI&T engineer, the ME group oversaw the 
assembly of all system components onto the main CanSat structure. At implementation the ME 
group, again at the direction of the AI&T engineer, is responsible for the verification of not only 
the mechanical tasks the CanSat must perform, but for the verification of its structural ability to 
transport and protect all the components (mechanical and otherwise) during operation. 

Tests at this stage no longer evaluate the viability of a technology but the performance of 
the final design. Drop tests no longer verify the selection of a material or the strength of a part, 
but verify the ability of all the subsystems to work together control descent. Drop tests verify the 
ability of the structure survive protect the components that are now integrated onto it rather than 
the ballast that was used before. Vibration tests verify the torques on fasteners are adequate to 
resist backing out. Additionally, processes are now tested vigorously to affirm that components 
perform as designed and do not interfere with other subsystems that may be operating 
concurrently and that all contingencies are accounted for. Even routine electrical tests are of 
concern to the ME group because the tests are being performed while mated to the structure - 
which could alter the results from the sub-system verification tests done before integration. 
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5.3 Descent Control Subsystem 
5.3.1 Proof of Concept 


The focus of the DCS design was the completion of the autonomous landing bonus 
objective. To achieve the best and most appropriate design, the DCS team worked together to 
create a design through collaboration and can be seen in Figure 11. To control AoA and the 
descent of the CanSat, the design introduced the use of ram-air control arms (RCA) to translate 
the servo arm movement over a longer area to better control the ram air. To prevent unwanted 
movement in the RCAs (past 90‘), a partition was fitted to the RCA’s connection with the servo 
arm. Therefore the only movement experienced by the RCAs is the upward movement provided 
by the upward force of the ram air, and once deployed they remain stiff to provide the needed 
ram air control. To insure design quality for the DCS, a proof of concept was developed and can 
be seen in Figure 11. 



Figure 11. DCS Strategy Overview Diagram. 


5.3.2 Development and Testing 


The second stage of the design process for the DCS will be testing of the proof of 
concept. Through appropriate testing we can verify functionality of the separate parts making up 
the DCS and better understand design failure points. Identifying failure points within the design 
allows the DCS team to identify any challenges with construction or components which may 
need to be replaced. 
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It is important to develop and test two key components within the DCS which is the 
software and hardware of the system. Testing of these two components will allow the team to 
verify the system meets the CanSat competition requirements for the autonomous bonus mission 
and verify the design concept. To best do this the DCS must undergo five tests concerning many 
aspects of the entire system. 

5.3.2.1 Controlled Environment Drop Tests 

The first of many tests is meant to test four hardware aspects of the DCS in a controlled 
no wind environment. 

The first DCS hardware component being tested is the deployment of the ram air control 
arms (RCAs). Testing of this component will give the team a better picture of the friction the 
arms may experience upon deployment from the CanSat and the upward force the arms will 
experience. This test will verify the connection strength and the structural integrity of the RCAs. 

The second and third aspect of the DCS tested will be the determination of the RCA 
lengths which is directly related to testing of the ram air. Determining the best combination of 
ram air to DCS connection can provide for the best control over the CanSat upon descent. Each 
RCA have 0.5m spaced out holes along the entire length of the arm in order to test different 
positions the chord lines of the ram air can be tied off to. This test will help verify the best 
length of the RCA and where the ram air will be connected to the RCAs. 

The last and perhaps one of the most important aspects being tested and analyzed is the 
vertical velocity, horizontal velocity, and the angle of attack. Understanding these three aspects 
can better prepare integration of the software with the hardware concerning the DCS. This test 
will verify that the CanSat will have a vertical descent velocity between 2.4 m/s - 4.6 m/s, a 
requirement set by the CanSat competition. The test will further verify that we have a horizontal 
velocity of around 0.5 m/s, a value determined by the DCS team. In completion, the test will 
also verify the angle of attacks the CanSat will experience upon drop and help the team better 
understand the movement of the CanSat under certain angle of attacks. 
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5.3.2.2 Variable Wind Drop Tests 


The variable wind drop test will be performed outside with the presents of wind to provide a 
more real time scenario. The test will verify all the results from the controlled environment drop 
test with the presents of wind. 

5.3 .2.3 Wind Tunnel Tests 

The wind tunnel test in a more hardware aspect of the DCS is meant to test the servos 
capabilities and verify its functionality under real scenario conditions. From a software 
perspective, the wind tunnel test will allow the DCS team to perform PID tuning and determine 
angular rates for control. This test will verify the overshoot and steady state error the CanSat 
will experience and thus provide values the team can use for competition. 

5.3 .2.4 Remote Control Drop Tests 

Further along in testing and once determining positioning of the ram air, remote controlled 
testing will take place. This will verify the controllability of the ram air and further test the 
capability of ram air aerodynamics. 

5.3.2.5 Rocket Launch Tests 

To verify the entire DCS system before competition, a rocket launch test and deployment of 
the CanSat will take place. This will test the entire autonomous system under real conditions and 
verify the results of previous testing. 

6 Additional Systems Engineering Activities 

Working on a set budget of one thousand dollars makes design to cost and value 
engineering plays a large role in CanSat development. It has been essential to minimize cost 
wherever possible in order to be able to fund more expensive aspects of the launch unit. One of 
the largest design changes that have been made in order to save money is altering the internal 
structure design. It initially depended upon machined aluminum base plates to hold the CanSat 
together. It would have cost over five hundred and fifty dollars to have a machine shop produce 
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the plates. This was unacceptable since that was over half of the budget. Therefore we opted for 
a simpler fiberglass base plate design that can be built by the team in house for less than twenty 
dollars. By eliminating the need for skilled labor we were able to drastically reduce construction 
costs. Use of common of the shelf components whenever possible has played a critical role in the 
value and design to cost engineering efforts. 

Long-Lead items were also minimized by keeping as many construction aspects as 
possible in house. By not relying on custom out of house components the team is able to remain 
in complete control of when and how components are produced. The few long-lead items that 
were encountered (mostly shipping times for certain components) were accounted for by 
ordering early in the design process as soon as it was established that they would be needed. 

This allowed plenty of shipping time while the team finalized the design. This minimized the 
time spent by the team waiting on parts. 

7 Conclusion 

The CanSat project is a complex systems engineering project which spans many technical 
disciplines. Through the application of system engineering tools; however, a complete solution 
to the 2009 mission has been developed. Currently, the team is on schedule to meet all of the 
competition requirements necessary for a successful mission. 


8 APPENDIX 

Table 24. Verification Method Definitions [1], 


Verification Method 

Definition 

Analysis 

Verification method that utilizes evaluation of data 
generated by accepted analytical techniques or 
simulations under defined conditions to show the item 
will meet the specified requirements. 

Demonstration 

Verification method that utilizes a qualitative exhibition 
of function performance, usually accomplished with no 
or minimal instrumentation. 

Inspection 

Verification method that utilizes an examination of the 
item against applicable documentation to confirm 
compliance with requirements. 

Test 

Verification method utilizing operation of all or part of 
the item under controlled conditions, either real or 
simulated, to determine that the quantitative design or 
performance requirements have been met. 
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Figure 12. Launch Vehicle Layout for CanSat. 


48 



J 


Figure 13. CanSat Power System Block Diagram. 
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